To provide sufficient quality of service (QoS) in an effective, but simple way is an important issue in the third generation partnership project (3GPP) standardization. In Rel 8 of this standard, the QoS concept is revised and the main difference from the previous concept is that network initiated QoS profile is introduced and the number of signaled parameters over the radio access network (RAN) is significantly reduced. When a new session is starting then the session initiation protocol/service discovery protocol (SIP/SDP) is used to signal the QoS needs to the proxy call session control function (P-CSCF). Then the policy and charging rules function (PCRF), using subscription data, formulates the proper QoS profile and forwards it to the relevant nodes in the core network (CN) and RAN.
The QoS profile contains the so-called Label parameter, the Allocation Retention Priority (ARP) parameter, and the uplink-downlink (UL-DL) Maximum and Guaranteed Bit-rate (MBR, GBR). The Label is a simply integer (or pointer), which specify a certain QoS class, and it is associated with a set of QoS parameters in the radio base station (RBS), which are configured by the operator via the operations support system (OSS). Two main types of Labels can be distinguished: GBR Labels, where the RAN has to perform admission control; and Non-GBR Label, which provides a best-effort type service. The allocation retention priority (ARP) specifies the importance of the bearer setup/modification request from the core network. The MBR specifies the maximum rate that may be given to this bearer in uplink/downlink respectively. The GBR specifies the bit-rate that the RAN should “guarantee” to have available for this bearer.
Obviously, the basic condition of providing the sufficient QoS is to handle the RBS resources properly, according to the QoS concept.
FIG. 1 shows how the RBS capacity is divided among the different types of services. The diagram shows the served traffic, ST, as a function of time, t. The area of the diagram denoted 10 is the served traffic of GBR bearers, which is the same as the traffic load of the GBR bearers and, the area denoted 12 is the served traffic of the non-GBR bearers, which is less than or the same as the traffic load of the non-GBR bearers. 18 illustrates the aggregated cell capacity as a function of all radio resources and all active users' location. In the following the main properties of the RBS capacity management according to the QoS concept is summarized:                Basically, the RBS capacity is divided into two main parts, namely GBR capacity 14, which is fixed and Non-GBR capacity 15 which varies (mapping according to the Label). This division is allowed by the so-called AAT (Absolute Admission Threshold), denoted with 16 and which defines a load-level (measured in kbps) which the aggregate GBR traffic should not exceed during an average time period;        The GBR traffic should be proceed by CAC function using the QoS descriptor, the current GBR load on the RBS and the AAT value;        Both GBR and Non-GBR part of capacity can be divided further into so-called GBR and Non-GBR partitions;        In case of GBR traffic an absolute capacity threshold (like independent AATs) can be defined for each partition;        The non-reserved part of the GBR traffic is distributed among the Non-GBR partitions. Hence the capacity for Non-GBR traffic is time varying, so absolute thresholds for the partitions cannot be defined. Instead the Relative Committed Rate (RCR) is introduced, which is used to specify the percentage of the total currently available capacity for each Non-GBR partition;        If a non-GBR partition is not fully utilized, then other non-GBR partitions may share the available resources among them, according to their RCR value.        
The long term evolution (LTE) RAN consists of the following entities: a user equipment (UE), an air interface between the UE and a radio base station (eNodeB), eNodeB and a RAN transport network with different types of transport equipments between the eNodeB and the CN.
In order to guarantee the sufficient QoS in the LTE RAN adequate scheduling/queuing/resource allocation mechanism and techniques are needed between the UE and the CN. Basically the UE-CN connection may be distinguished into two main parts: UE-eNodeB and eNodeB-CN (which herein is called the LTE RAN transport network) connections.
Between the UE and the eNodeB, the QoS is guaranteed by the UE and eNodeB using proper scheduling mechanisms.
Since the RAN transport network consists of standard (third party) equipments, the QoS may be guaranteed only by using the existing and standardized functions on a proper way.
FIG. 2 shows a simplified view of the LTE RAN transport network. The eNodeBs 21 (two are shown in FIG. 2) are communicating with the CN 23 via the IP/Ethernet 24 over the S1 interface 25, which is used to realize the transport connections between the eNodeBs 21 and the CN 23. The X2 interface 26 is used to realize the transport connections between any two neighbouring eNodeBs 21. Neither the S1 interlace 25 nor the X2 interface 26 has flow control. A network management system 28, such as the OSS-RC, manages the eNodeBs 21 over the Mub interface 29.
The sufficient QoS in the LTE RAN transport network may be provided in the following ways:                Simple priority queuing: On IP level the differentiated services code point (DSCP) field, while on Ethernet level the p-bits may carry priority information, which is considered in case of scheduling in the transport nodes. Different types of priority queuing mechanisms may be used, like strict priority queuing, weighted fair queuing (WFQ), etc. In WFQ, the resources are shared between the different queues according to their weight. The unused resources are divided between the queues which needs more resources according to their weights.        Signalled provisioning: which means that a radio bearer/access bearer (RB/AB) may only be established when the required transport capacity is available. The main issues here are the on-line monitoring of transport resources, informing the radio level connection admission control (CAC) about the result of transport level CAC, and reserving the sufficient transport resources;        Bandwidth broker: in this case the CAC decision and network resource handling is provided by the bandwidth broker, but obviously it requires an extra equipment in the network;        Static provisioning: A simple CAC mechanism is needed into edge eNodeBs and CNs, but correct operation is guaranteed only by using proper network dimensioning. This solution—from its static behaviour—cannot react to the extraordinary situations;        Over dimensioning: CAC is not required, however network utilization is very low, and extraordinary situations cannot be handled.        
The above presented solutions—although those are able to guarantee some QoS level—cannot work together with the LTE QoS concept because of the following reasons:                Priority queuing provides only simple differentiation but it does not provide any bandwidth guarantee, which is a basic requirement for fulfilling the LTE QoS concept;        Signalled provisioning, bandwidth broker based solution and static provisioning is not considered, because it requires extra interaction between the transport and the LTE devices;        Over provisioning is also not sufficient, because it cannot provide the sufficient QoS level on a cost effective way.        
To guarantee proper QoS three main tasks should be solved:                Correct mapping of radio level QoS information onto transport level QoS fields (in this case these are DSCP or/and p-bit field);        Proper transport network dimensioning according to the LTE QoS concept;        Proper queuing/scheduling mechanism in the transport nodes for providing the same traffic classification as in the LTE QoS concept.Mapping        
If any different GBR or Non-GBR partitions are mapped to the same DSCP or p-bit value then the QoS concept cannot be guaranteed, because in case of packet dropping there is no way to distinguish the traffic partitions in the transport node, so the individual dropping probability cannot be guaranteed any more.
Network Dimensioning
The transport network has been dimensioned such that the GBR traffic may be handled in any network situation. Since the Non-GBR traffic is a best-effort type of service the non-GBR partitions do not have any minimum bandwidth requirement in the transport network.
Priority Queuing
The main problems with the priority queuing mechanisms are the following:                Strict priority queuing is not sufficient, because it does not make it possible to share the available bandwidth among the different traffic partitions according to the LTE QoS concept. The high priority traffic may eat the radio resources.        Typically the transport network is not dimensioned for peak cell rate, because the statistical multiplexing gain is considered. However, in this case the other queuing mechanisms, like WFQ cannot guarantee the QoS classification in the transport network according to the RBS resource distribution.        
The critical problem is that the current priority queuing/scheduling mechanisms are not enough to provide the LTE QoS concept. The problem appears if more than one Non-GBR traffic partitions are used and the available transport capacity is less than the aggregate traffic of the eNodeBs (the transport is a bottleneck). In this case packet loss occurs, however the current priority queuing schemes are not able to provide the same packet loss—in a fair way—for all Non-GBR traffic partitions, as seen from the following simple example, shown in conjunction with FIG. 3. FIG. 3 shows a first eNodeB 21a and a second eNodeB 21b. Both eNodeBs handles 120 Mbit/s traffic. The first eNodeB 21a is connected to an Ethernet switch 32 in the transport network with a link A having a capacity of 100 Mbps and the second eNodeB 21b is connected to the 32 with a link B having a capacity of 100 Mbps. The 32 further has a link C connected to an upper level node having a capacity of 180 Mbps. The terms GBR1, GBR2 are the GBR traffic from eNodeB1 and eNodeB2 respectively, NGBR11, NGBR21 are the Non-GBR traffic from eNodeB1 and eNodeB2 respectively for partition 1 and, NGBR12 and NGBR22 are the Non-GBR traffic from eNodeB1 and eNodeB2 respectively for partition 1.
Both eNodeBs 21a, 21b are able to generate 120 Mbps peak traffic. The capacity handling in both eNodeBs is the same:
eNodeB 1 and eNodeB 2CapacityCapacity for GBR traffic (GBR1, GBR2)20 Mbit/sCapacity for Non-GBR partition 1 (NGBR11, NGBR21)50 Mbit/sCapacity for Non-GBR partition 2 (NGBR12, NGBR22)50 Mbit/sTotal capacity120 Mbit/s 
According to the QoS concept the link capacities will be divided between the different traffic partitions according to the following way:
GBR trafficNGBR partitionsTotal capacityLink A and B20 Mbit/s40 Mbit/s for each100 Mbit/sLink C40 Mbit/s70 Mbit/s for each180 Mbit/s
Taking the following traffic situation:
eNodeB 1GBR1NGBR11NGBR120 Mbit/s100 Mbit/s20 Mbit/seNodeB 2GBR2NGBR21NGBR220 Mbit/s 60 Mbit/s60 Mbit/s
All traffic can be served by the eNodeBs 21a, 21b, however the transport network is a bottleneck. The loss for the NGBR classes is on link A and B, respectively:
Link ANGBR11NGBR1220% (100 Mbit/s→ 80 Mbit/s) 0% (20 Mbit/s → 20 Mbit/s)Link BNGBR21NGBR2217% (60 Mbit/s → 50 Mbit/s)17% (60 Mbit/s → 50 Mbit/s)
The loss for the aggregated traffic of the NGBR classes on link C, assuming that both eNodeB's traffic receive equal traffic loss. The reference capacity for the loss value is the original traffic.
Link CNGBR11NGBR1233.32% (100 Mbit/s → 67.68 0% (20 Mbit/s → 20 Mbit/s)Mbit/s)NGBR21NGBR2220% (60 Mbit/s→ 42.32 Mbit/s)17% (60 Mbit/s → 50 Mbit/s)
To see the loss values of the table it is clearly seen that using fixed scheduling weights in the transport network results in a completely unfair capacity handling, because the different traffic classes receive different loss in the transport. The fair solution would be if all traffic classes receive the same loss, which in this case is 25% (240 Mbits/s→180 Mbit/s).
One main problem is that the eNodeB resources may be allocated to the different Non-GBR classes in a very flexible way, which cannot be reproduced by the standard scheduling mechanisms, like WFQ.
A possible way could be if the WFQ weight system is periodically updated according to the current traffic situation in the eNodeBs. However this solution has several significant drawbacks:                All bearer establishment/modification/release require WFQ weight updates in some transport nodes.        The above modification process requires a central entity, which maintains an actual resource database for the transport network and it is responsible for process all configuration changes that are required.        Information changing is needed between the eNodeBs (mobile network) and the transport network (configuration of transport nodes), which could be problematic if the mobile and transport networks are in the hand of different operators.        
Consequently, a solution is needed, which does not require any on-line cooperation between the base station and transport devices.